Trick-play modes for pre-encoded video

ABSTRACT

An inventive method provides various reproduction modes by controlled selection of replay locations. Selection within a video stream or between separate video streams derived for selected trick-play speeds may be facilitated. The method allows selections to be decoded and displayed independently from a previously video stream selection. The method comprises the steps of: identifying a digitally encoded set of signals in a storage medium for each one of a plurality of video programs for reproduction of each one of said plurality of programs at a plurality of reproduction speeds; linking each of the encoded signals in each of the sets to one another at predetermined jump points; reproducing one of the encoded signals in response to selection of a program and a reproduction speed; jumping to different ones of the encoded signals for the reproducing in accordance with the predetermined jump points, in response to subsequent selections of different reproduction speeds; and, decoding the reproduced signals for display of the selected program at the selected reproduction speeds.

This invention relates to digitally compressed video material and inparticular to the provision this material at speeds other than at normalplay speed.

BACKGROUND OF THE INVENTION

The implementation of trick-play modes within digital video systems is aproblem which is becoming more important as digital video-based systemsenter the marketplace. Emerging consumer video products such as video ondemand (VOD), video CDs, and other similar systems may compete with theVHS tape market as providers of feature-length movies. However, unlikeanalog-based replay methods, digital video systems represent a challengein the reproduction of video images at speeds other than normal playspeed. Such “off speed” reproductions being known as trick-play whichmay provide images at various speeds, for example, fast-forward,fast-reverse, freeze-frame etc.

In European Patent application number EP A 0625857 a video server isdisclosed which provides video signals to a user responsive to controlsignals received therefrom. Application EP A 0625857 teaches the use ofa real time signal and an exemplary 10 times speed special signal whichare linked to permit selection therebetween without programdiscontinuity. The special signal is processed such that itstransmission rate is no higher than that of the real time signal.Special signal processing is acheived by omitting inter-frame coded datafrom the MPEG bistream. Application EP A 0625857 recognizes therequirement to restrict the transmission rate of the trick play orspecial signal and as a consequence of omitting inter-frame coded datamust recalculate time stamps.

SUMMARY OF THE INVENTION

The invention relates to a method for reproducing a video program withselection between normal play signal and trick-play signal havingreduced resolution. The selection between modes being controlledselection of “replay” locations. The method allows successive selectionsto be decoded and displayed independently from any previously selectedvideo stream.

According to the invention, a method for reproducing from a storagemedium, one of a plurality of video programs at a plurality ofreproducing speeds wherein selection of ones of the plurality of speedsare linked at predetermined jump points, the method comprising the

steps of:

-   -   a) selecting one of the plurality of video programs for        reproduction;    -   b) selecting a reproduction speed for the one of the plurality        of video programs;    -   c) selecting a digitally encoded signal from a set of signals        corresponding to the one of the plurality of video programs        responsive to the reproduction speed;    -   d) reproducing the digitally encoded signal from the set of        signals;    -   e) jumping to different ones of the encoded set of signals for        the reproducing in accordance with the predetermined jump        points, in response to subsequent selections of different        reproduction speeds;    -   f) decoding the reproduced signals for display of the selected        program at the selected reproduction speeds; and,    -   wherein the step c) further comprises selecting the digitally        encoded signal from the set of digitally encoded signals        corresponding to different speeds of reproduction with differing        resolution values.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 shows table 1 which indicates advantageous bit rate andresolution differences for both normal and trick-play modes.

FIG. 2 illustrates compressed video data streams representing normalplay speed, twice play speed and ten times play speed.

FIG. 3 illustrates table groups for use in an inventive method forselecting between bit streams representing normal and trick-playreproduction speeds.

FIG. 4 is a block diagram illustrating a system employing inventivefeatures for selection and control of compressed digital video sources.

FIG. 5 is a flow chart illustrating operation of an inventive method ofselection and control of compressed image streams for reproduction atnormal and trick-play speeds.

DETAILED DESCRIPTION

This inventive method facilitate various trick-play modes by controlledselection of “replay” locations. Depending on the program storage mediuma single stream may provide normal play speed and trick-play operation.However, the provision of both normal play speed and trick-playoperation from a single program stream may result in trick-play speedslimited by the GOP size or I frame repetition rate. To provide a greaterselection of trick-play speeds multiple program streams may be used witha single stream for normal play speed operation with other streamsproviding a variety of fast-forward and fast-reverse trick-play modes.The image streams which provide the trick-play feature may notnecessarily be encoded at the same bit-rate, and may not necessarilyhave the same resolution as the original image stream. The use of asignificantly lower bit-rate and/or resolution for encoding trick-playimage streams may offer savings benefits when storage space and/ortransmission costs are considered. In addition, human visual perceptionmay also allow these trick-play image streams to be processed further toreduce resolution, and hence storage and transmission costs duringtrick-play video operation, without compromising perceived imagequality.

As mentioned this method may be applied to various forms of videomaterial, analog or digital and encoded in a variety of ways. However,in this description of an exemplary system, it is assumed thattrick-play streams are encoded in an MPEG format with the followingparameters:

-   -   there is one normal-play (normal speed) MPEG video stream,    -   two fast-forward streams are required, 7× & 21× normal speed,    -   two fast-reverse streams are required, minus 7× & 21× normal        speed.        However, this method may be applied equally effectively to a        variety of other speed configurations.

In the exemplary system, five separate MPEG-encoded streams arerequired. These streams are completely independent and may be of varyingbit-rates and/or varying display resolutions. For example, one possibletrade-off between quality and memory efficiency is illustrated in table1 shown in FIG. 1. Table 1 shows trick-play streams employing lowerresolution, 352×240 pixels and a lower bit-rate, 1.5 Mbps than thenormal-play stream, 704×480 at 4.0 Mbps. This trade-off is fullyacceptable since high spatial picture quality may result in trick-playresolution beyond human visual perception. Hence the trade-off inresolution and bit rate results in more efficient storage utilization.The extra memory capacity required to store all forward and reversetrick-play streams may be calculated by summing each trick-play bit-ratedivided by the trick-play speed for each trick-play speed and expressingas a percentage of the normal play speed bit-rate.${{Extra}\mspace{14mu}{storage}\mspace{14mu}{required}\mspace{14mu}{as}\mspace{14mu}{percentage}} = {\frac{{2\left\lbrack {1.5/7} \right\rbrack} + {2\left\lbrack {1.5/21} \right\rbrack}}{4} \times 100\%}$

-   -   extra storage required=14.37%

Thus four trick-play data streams may be accommodated with approximately15% extra storage capacity. A reverse normal play feature may beprovided, which may appear to increase trick-play storage capacityrequirements by 100%. However, such a reverse normal play feature may befacilitated with, for example, bit rate and resolution reductions. Thusthe reverse normal play feature may require approximately 37% extrastorage capacity, which when added to the other trick-play streamsrepresents a storage capacity increase of about 50% of the normal playstream requirement.

As video material is read or replayed from the video server to theuser's decoder, the server may be switched between the various streamsin response to user instructions. For example, the user may select, viaa remote control command, the highest fast-forward speed to rapidlylocate a particular point in the material. The fast-forward controlcommand results in the server readout address jumping, from the currentlocation in the normal-play stream to the corresponding appropriatepoint within the 21× fast-forward stream and continue playing. Eachtrick-play and normal-play streams should comprise relatively uniform,short group of pictures (GOP) having a size of, for example, half asecond. This GOP size yields a worst case visual continuity error of0.25 seconds, i.e. time to reach the nearest I frame entry point whenswitching between bit streams.

An important part of the overall system is the method for determiningswitching entry points between the different image streams. For example,during “playback” of one stream a user may wish to switch to anotherstream. This switch requires calculation of the exact location in thenew stream, to a byte accurate level, that the decoder should begin to“play” from. The determination of the “entry point” in the new streammay be derived as follows:

-   -   1. Determine the current byte offset, and hence the current        frame in the current file.    -   2. Determine the new frame to switch to in the new file.    -   3. Determine the byte offset in the new file.        Step 2 is complicated by the fact that, for MPEG streams, the        entry points into a new stream are limited to those points where        a sequence_(—)header exists, which is typically at an I frame at        the beginning of a group of pictures (GOP). It is further        complicated by the fact that the duration of the real display        time of a GOP is not always constant even if the number of        frames in a GOP is constant. This complication arises from the        possibility to repeat fields (or frames) in an MPEG sequence,        with the result that more final ‘displayed’ frames can be        produced by a single GOP than there are coded ‘pictures’ within        the GOP.

An example of stream switching is illustrated in FIG. 2. In FIG. 2, thenormal speed image stream is being read or “played” from a storagemedium, and two trick-play image streams are available on the medium forreproduction at 2× and 10× normal speed. The trick-play speeds of 2 and10 times are selected for illustration simplicity. At the instant ofuser trick-play selection or switching time, the normal play imagestream is at frame number 20. Possible entry points into each of thethree streams are determined by sequence headers which are depicted bydarkened frames in FIG. 2, and typically begin a group of pictures(GOP). The “best fit” frames which can be switched to are pointed to bythe arrow head line which links the entry points in the various videostreams. The “ideal” or desired entry points, in terms of the usersvisual continuity, are indicated in FIG. 2 by horizontally shadedframes. Note that these “ideal” points are not necessarily calculatedsimply from (current frame in normal sequence)/(trick-play stream speed)due to the complications of displayed and repeated frames describedabove. In each case, the actual frame selected is a “best fit” possibleentry frame which is closest in time to the users desired or “ideal”frame. From the illustration in FIG. 2, the decision of which frame toswitch to may appear to be obvious. However, from an algorithmic pointof view this is far from trivial. An important part of the overallsystem is the method of determining the switching points between thedifferent streams. To accomplish this function, a look-up table, LUT maybe employed which may be pre-recorded on the program storage medium. Thefunctionality and arrangement of this exemplary look up table isdescribed in Table 2 which shows the general layout.

TABLE 2 [number_(—)of_(—)tables] [Table_(—)number] {file_(—)name}<bit_(—)rate Mbps> [num_(—)gops] [num_(—)frames] [gop_(—)size][1st_(—)gop_(—)size] [speed] [gop number] [file byte offset] [gopnumber] [file byte offset] [gop number] [file byte offset] . .  Repeated [num_(—)gops] times . [gop number] [file byte offset] [gopnumber] [file byte offset] [gop number] [file byte offset] . . Repeatall of above (except first line) [number_(—)of_(—)tables] times . TABLE2 Parameter Definitions: [ ] denotes an integer value, < > denotes afloating point value, { } denotes a text string,[number_(—)of_(—)tables] The number of look-up tables in the file is thesame as the number of bit streams. In exemplary FIG. 1 there are 5streams thus [number_(—)of_(—)tables] is 5. [Table_(—)number] Is anumber which is associated with the ordering of the streams. This numbermust be between 0 and [number_(—)of_(—)tables] − 1. [Table_(—)number]also shows the order of the streams from fastest reverse to fastestforward. {file_(—)name} The name of the muxed MPEG stream. <bit_(—)rate>The rate in Mbits/second of the muxed MPEG stream including transportlayer overhead. [num_(—)gops] The number of GOPs in the video stream.[num_(—)frames] The total number of frames in the MPEG video stream.[gop_(—)size] The GOP size in displayed frames taking into account 3/2pull down if necessary. [1st_(—)gop_(—)size] The size in displayedframes of the first GOP. Usually this will be [gop_(—)size] - M + 1.Where M is the distance between I and P frames in an MPEG stream [speed]Speed of the trick-play stream including sign.

The exemplary look-up-table, LUT of Table 2 may be stored in the systemmemory during playback of the video material. When the user changes fromone speed to another, the information in the LUT is used to locate thecorrect, or corresponding point, in the new stream at which to startdecoding. The information in the LUT is needed for this purpose togetherwith the current offset, in bytes in the current bit-stream beingplayed.

To initiate switching between streams the current GOP is determined fromthe current file offset by searching through the look-up table to findthe GOP start point which corresponds to the current file offset (seeTable 2). Once the current GOP is known, the new GOP, gop_(—)new, may becalculated from the old GOP, gop_(—)old, using equations 1 and 2, andthe following parameters, speed_(—)new, speed_(—)old, gop_(—)size andfirst_(—)gop_(—)size;gop _(—) new=[(old _(—) frame*old _(—) speed/new _(—) speed)+(gop _(—)size−first _(—) gop _(—) size)]/gop _(—) size  Equation 1.where old _(—) frame=gop _(—) old*gop _(—) size−(gop _(—) size−first_(—) gop _(—) size)  Equation 2.Having calculated the new GOP the look-up table appropriate to the newspeed is searched to find the file offset which corresponds to the newGOP. The new stream may then be played starting at this new file offsetpoint. The relative simplicity of this system results in efficientswitching between different streams. However, this method is based onreal time calculation of the new GOP with the assumption that thestreams contain GOPs which produce a constant number of displayed frames(denoted by gop_(—)size). If this is not true, due to either a varyingGOP structure used to encode the stream, or a non-constant field repeatpattern within the source material and the use of de-telecine duringencoding, then the above equations will not hold true.

In view of the possibility of these assumptions being false, i.e. it isnot known in advance exactly how many frames will be produced by a GOPwhen decoded, it may not always be possible to accurately calculate, inreal time, the point at which to enter the new bit stream given thepoint in the current stream unless a complete “time-map” of the newstream is available. This is because even if the current “real time”frame number is known, the calculation of which picture number in thenew stream corresponds to the same point in time is not possible ifequations 1 and 2 are not valid. In addition to this practical problem,it is also advantageous to have the ability fine tune the streamswitching delay and accuracy independently from the actual switchingsoftware. For these reasons an advantageous look-up table method isdisclosed, which lists “entry points” thus avoiding both real timecalculation of the second step, and the attendant problems of repeatedframes. The advantageous look-up tables are assembled “off-line” and maybe stored together with the corresponding program stream. The use ofpreprocessed look-up tables allows the entry point determination andtuning of stream switching delays to be performed independently from thesoftware which utilizes the tables.

The use of these generic look-up tables containing entry, or jump topoints for the various play and trick-play streams requirescomparatively simple software control. Hence, user controls may beadvantageously provided to facilitate fine tuning or modification of thestream switching delay independently from the actual switching controlsoftware. For example, a user may, in the interest of continuity ofentertainment, opt to always join the new image stream ½ or 1 secondprior to the departure point in the first stream, in this way “program”image continuity may be sustained. In addition such an “off set” entrypoint may advantageously compensate for user reaction time.

In addition the user may be provided with the ability to determine theaccuracy, resolution or granularity of the look-up tables. For example,since “jump to” address occur at each I frame clearly the highestresolution is obtained when every I frame in each stream is included inthe LUT. This level of resolution maximizes the look-up table memoryrequirements. However, fewer I frame addresses in the LUT will reducememory requirements but may introduce user frustration even if the jumpto address is automatically corrected to include otherwise lost programimages. These user control preferences may be facilitated independentlyfrom the actual switching control software. Hence the control softwarenever requires modification even when a switching scheduling change isnecessary. A conceptual illustration of 2 look up tables or LUT sets isshown in FIG. 3. FIG. 3 illustrates possible transition destinationsfrom normal play speed and 7 times play speed. Similar sets of tablesare required for transitions from 21×, −7× and −21× trick-play speeds.

This method of look up table based switching may be explained asfollows. A system with N streams provides the ability to switch to andfrom any stream, and comprises a normal play stream and varioustrick-play streams. Hence for each stream there are N−1 tables of(byte-offset, byte-offset) pairs required. The first offset in the paircorresponds to the point or location being viewed in the current stream.The second offset refers to the same point in time (program location) inthe stream to be switched to.

This mutliple table method may be further explained as sets of nestedaddresses. For example, with reference to the table for transitions fromnormal play speed to seven times speed there are seven “from” byteaddresses for each “to” byte address. Thus, for each of these seven NPGOPs there is only one GOP to go to in the 7 times speed stream.Similarly for transitions from normal play speed to twenty one timesspeed there will be 21 NP GOPs which are directed to a single GOP in thetwenty one times stream. However, for a transition from twenty one timesspeed to normal play speed there is a single NP GOP which corresponds tothe current 21 times GOP. Hence for transitions from slower to fasterplay speeds the jump-to addresses may be considered as sets of nestedaddresses. However, transitions from faster to slower speeds results insingle corresponding jump-to addresses.

Table 3 illustrates the general layout of this look up table method. Thefrom/to table entries may be assembled by a software routine which isapplied to the pairs of program streams. For example, to assemble thetable for transitions from normal play speed to seven times speed thetwo program streams are partially decoded or parsed to locate GOPheaders. The headers for each stream are the assembled into a table,which as described will have seven NP addresses for each 7 times speedaddress.

In Table 3, the location in the current file or video stream beingswitched from is indicated by [“from” byte offset N] which is the offsetin bytes. The location in the new file, or video stream where decodingis to start is indicated by [“to” byte offset N], which is the offset inbytes. The [num_(—)pairs] is the number of pairs of switchingcoordinates in the file. The number of pairs of coordinates in eachtable depends only on the required precision or granularity whenswitching between streams, i.e. fewer pairs save storage space butprovide fewer locations at which to join the new stream. However, theupper limit for accuracy is still governed by the number of GOPs andhence, the number of possible entry points in the stream being switchedto.

TABLE 3 [“from” byte offset 1] [“to” byte offset 1] [“from” byte offset2] [“to” byte offset 2] [“from” byte offset 3] [“to” byte offset 3] . .  Repeated [num_(—)pairs] times . [“from” byte offset <num_(—)pairs−1>][“to” byte offset <num_(—)pairs−1>] [“from” byte offset <num_(—)pairs>][“to” byte offset <num_(—)pairs>]Hence, for a system employing N video streams, each stream will utilize(N−1) tables. These tables are used as follows,

-   -   for switching from stream S1 to S2 (table T_(—) 1 _(—) 2),    -   from stream S1 to S3 (T_(—) 1 _(—) 3),    -   from stream S1 to S4 (T_(—) 1 _(—4) . . .)    -   and S1 to SN (T_(—) 1 _(—)N).        For example, if a current image location is at offset O1 in        stream S1 and switching to stream S3 is required, the following        operation is required:    -   1) Find the closest (in time) “from” offset in table S_(—) 1        _(—) 3.    -   2) Read the corresponding “to” offset from the same table.    -   3) Start decoding stream S3 from the “to” offset value read.        The storage overhead resulting from these tables is still        relatively minor when compared with the storage space required        by the video streams. The storage overhead for these tables may        be calculated based on the following assumptions;    -   encoded two hour movie (7200 second)    -   Trick-play streams of +7×, −7×, +21×, −21×,    -   GOP length of 0.5 seconds,    -   bit rate of 4 Mbps, (thus movie=3.6 Gbytes)        There are;    -   4×LUT of 14,400 entries (NP stream addresses)    -   8×LUT of 14,400/7 entries (7× TP addresses)    -   8×LUT of 14,400/21 entries (21× TP addresses)    -   Total=79,543 entries, and assuming 8 bytes/entry,        Overhead=636,344 bytes $\begin{matrix}        {{{Overhead}\mspace{14mu}\%} = \left( {636,{{344/3.6}\mspace{14mu}{Gbytes}*100}} \right)} \\        {= {0.018\%\mspace{14mu}{of}\mspace{14mu}{original}\mspace{14mu}{normal}\mspace{14mu}{play}\mspace{14mu}{stream}\mspace{14mu}{{size}.}}}        \end{matrix}$        In addition, all control and fine tuning of the switching        procedure (accuracy, timing, etc.) can be controlled by an        overlay software which alters of modifies the values and number        of entries read from the tables themselves without requiring        access to the control software.

A system employing the various inventive digital video source selectionmethods is depicted in FIG. 4. The system shown in FIG. 4 includes auser with, for example, a remote control capability provided by device525, and a display device 1000 for monitoring audio and video inputsignals. An interface unit 500, provides a control communication stream551 between the user's apparatus and a digital video source 10.Interface unit 500 also decodes a compressed digital video signal 511,derived from source 10 to produce audio and video signals which arecoupled to display device 1000. The control stream 551 is generated by acontrol transmitter 550 which forms part of interface unit 500. Thecontrol stream carries a plurality of control functions, for example,activation of user billing, user interactively such as program sourceselection, “trick-play” features or provision of a “virtual VCR” likeprogram source. The user may communicate with interface unit 500, via aremote control unit 525, or via manually activate switches (not shown).

Digital video source 10 comprises a control unit 50 which receivescontrol stream 551 and implements user requested tasks via a softwarecontrol program. For example, user originated commands may include, peruse billing, program selection, pay per view premium program selection,program manipulation or “trick-play” features. User control preferences,as previously described, may be facilitated by user preference controlsoftware depicted in block 60 which interacts with the main controlsoftware of block 50.

Multiple compressed digital video program sources are stored in astorage device within source 10. The storage device may comprise a solidstate memory, magnetic or optical memories or a combination of solidstate and magnetic or optical. For exemplary purposes only, thecompressed digital video programs depicted in FIG. 4, are shown asareas, or pages of memory with program P1 located on memory page 100,program P2 on page P101 and program Pn on page (99+n). Each programpage, comprises a program memory space 110, which contains thecompressed program for “reproduction” at normal play speed, for example,block NP for normal play. This normal play program may be represented bythe bit rate and resolution parameters shown in table 1, FIG. 1. Theprogram memory space 110, also contains various “trick-play” processedforms of the program, for example, TP1, “trick-play” speed 1 and itsreverse, and TP2, “trick-play” speed 2 and its reverse. As describedearlier, these “trick-play” versions of the program may beadvantageously processed to reduce, or minimize, their memoryrequirements. For example, as described previously, the provision offour “trick-play” speeds represents and additional memory requirement ofabout 15%. To permit switching between program play speeds, each programpage also contains inventive look up tables 120, which list from-toentry addresses as previously described.

Operation of the exemplary system shown in FIG. 4 may be explained withreference to the chart shown in FIG. 5. The user initiates contact withthe digital video program source 10 by means of the remote controlstream 551. This initial contact, or log-on may signal the start abilling period or event, or otherwise log user interaction with thesystem and is depicted in FIG. 5 as step 100, START. At log on the usermay be presented with a program selection menu from which his programselection is made. Control 50 of FIG. 4 receives the user command andselects, for example, Program 1 on memory page 100. This programselection is depicted at step 200 of FIG. 5. Having selected a program,information regarding the program is read from the storage medium andstored in the system memory of source 10. This information may includesystem data, for example, number of trick-play speeds, look-up tables,and various user choices, for example, display aspect ratio, language,rating etc. A test is performed at step 225 to determine if the userselected a play speed. If the user selected a normal play speed or NPmode, step 225 tests YES and the compressed digital program stream isread from the NP memory area of memory 110, as depicted by step 275 ofFIG. 5. Similarly, the user may have selected to view Program 1 in thereverse direction at the highest play speed, thus step 225 tests YES anda version of Program 1 is read from, for example, −TP2 memory area ofmemory 110. If the user failed to specify play speed, a default settingat step 250 is invoked which automatically selects normal play speedreproduction of the selected Program 1, at step 275 of FIG. 5.

Having commenced reproduction of Program 1 a test is performed at step300 to determine if a new play speed has been selected by the user. A NOat step 300 is tested further to detect the program end at step 700.Thus a NO at both steps 300 and 700 forms a loop which waits for eithera play speed change command or the program end. If test 300 is YES a newplay speed has been selected and the control system 50 of FIG. 4determines the byte offset address in the current program replay. Thisbyte offset determination is depicted as step 400 of FIG. 5. Havingreceived the user's new speed requirement, control system 50 selectsfrom memory area 120, a look-up table specific to the desired speedtransition. This look-up table contains pairs of corresponding from/to,or jump-to addresses. At step 500 the table is searched to locate thecurrent byte offset address, which represents the “from address” of thepair. The “to address” gives the corresponding byte location in the newspeed stream, from which reproduction will continue. The initiation ofthe new speed replay from the new address is depicted at step 600 ofFIG. 5. The jump-to address is derived as previously described to ensurethat the new program version may be decoded independently of adjacent orpreceding frames thus maintaining program continuity for the user.

User selected preferences for jump-to location and or jump-to addressgranularity may be provided during the initial selection of the programat step 206. For example, the look-up tables are recovered from thestorage device together other user selectable features such as,language, rating, aspect ratio, etc. The look-up tables may berecomputed or modified prior to actual use by preferences 60. Suchmodified jump-to addresses may advantageously result in the joining thenew program at a point which precedes the departure point of the old, orpreviously program.

Following initiation of the new speed program replay at step 600, thecontrol sequence loops back to steps 300 and 700 and waits for either afurther replay speed request or the end of the program. If at step 700tests YES, signifying the program end is reached, a further test isperformed at step 800 which determines if the user desires to view a newprogram. A YES at step 800 is coupled back to step 200 where the usermay select another program from the program selection menu. A NO at step800 indicates that the replay session is ended and interaction withsource 10 is terminated at the END step 900.

In FIG. 4, an exemplary switch S1 is depicted in memory page 100, forthe purpose of illustration only, in actuality the program stream isread from the appropriate play speed memory, i.e. NP, TP2 etc., startingat an address defined by the appropriate address pair from the specificlook up table of memory 120, associated with transitions from thecurrent speed to the new speed. Similarly the user may transition fromany current play stream to any other play stream by means of tables 120which list all possible entry points for each play speed.

Source 10 of FIG. 4 may be implemented as a consumer entertainment unitcontaining multiple programs. For example, a video juke box with an aprogram disk library and changer mechanism. Source 10 may comprise acombination of disk based programs coupled to an electronic buffermemory. The program disk may be MPEG encoded and in addition containapplicants' advantageous look up tables. These look up tables maycontain I frame track addresses which enable the disk replay transducerto jump successively between I frames in order to generate the desired“trick-play” reproduction speed. The storage requirements of these lookup tables is small, as has been discussed. However these tables must berecovered from the disk and be stored in an active memory prior toprogram replay in order to facilitate “trick-play” reproduction. During“trick-play” reproduction the disk replay transducer jumps successivelybetween I frames in a sequence derived from the jump-to tables. Forexample, at seven times forward speed the transducer is directed to jump“over” seven intervening I frames and reproduce only the eighth I frame.This play jump play sequence is repeated continuously until the programend is reached or the user makes a further selection. Gaps in thereproduced signal stream may be concealed by the use of a buffer memoryand image repeat rationales. The program disk may contain “trick-play”specific MPEG streams, temporally and spatially processed to facilitatesmoother visual presentation than obtainable with I frame onlyreproduction. Similarly these “trick-play” specific streams may be theaddressable by applicants' advantageous look up tables.

Source 10 may represent portable entertainment unit preloaded with aselection of compressed video programs or motion pictures for consumeruse within a household. This entertainment unit may be scaled up andcentrally located to provide multiple user access to the compressedprogram content. This centralized replay facility requiresbi-directional communication with the user in order to facilitate avirtual VCR with “trick-play” features described.

1. An apparatus for reproducing video programs, comprising: means forstoring a plurality of video program records, wherein each programrecord having a set of digitally encoded signal records representativeof said each program; means for linking said encoded signal records ofeach said set to one another at predetermined jump points for selectingreproduction from different ones of said set; and, wherein each said setof digitally encoded signal records has records of differing sizes forreproduction at a plurality of speeds.
 2. The apparatus of claim 1,wherein said predetermined jump points are grouped specific totransitions between similar temporal program events for reproduction atdiffering speeds.
 3. The apparatus of claim 1, wherein saidpredetermined jump points represent addresses of digital images withineach said set which substantially correspond with one another.
 4. Anapparatus for reproducing video programs, comprising: means for storinga plurality of video program records, each program record having a setof digitally encoded signal records; means for linking each of saidencoded signal records in each of said sets to one another atpredetermined jump points for selecting between said digitally encodedsignal records, wherein said linking means comprises N sets of tables,each set having (N−1) tables of said predetermined jump points for eachof N reproduction speeds; and, each said set of digitally encoded signalrecords having records of differing sizes for reproduction at aplurality of speeds.
 5. The apparatus of claim 1, wherein a record forreproduction at a normal play speed represents a largest byte record. 6.The apparatus of claim 1, wherein records for reproduction at speedsother than a normal play speed represent records smaller than saidnormal play speed record and have sizes which decrease in proportion toreproduction speed increase.
 7. An apparatus for reproduction ofcompressed digital images at a plurality of speeds, said apparatuscomprising: a storage device having stored therein compressed programrecords, each program record containing multiple versions where eachversion of said multiple versions allows reproduction at a differentplay speed, and tables of predetermined temporally similar addresseswithin each version of said each program record for selection betweenthe different play speed records; transducing means for reproducingimages from said compressed program records; and, control meansresponsive to user program selection for selecting one of said programrecords, and in accordance with a play speed selection selecting one ofsaid multiple versions, said control means being additionally responsiveto user determined new play speed for reading said tables and generatingpredetermined addresses within another one of said multiple versions fortransducing in correspondence with said user determined new play speed.8. The apparatus of claim 7, wherein said images are reproduced from atime which precedes the preceding version.